One of the critical aspects for achieving a cost-effective high-performance switch implementation is the architecture of the forwarding database search engine, which is the centerpiece of every switch design. Optimal partitioning of functions between hardware and software and efficient interaction between the search engine and its "clients" (e.g., switch input ports and the central processing unit) play a crucial role in the overall performance of the switching fabric.
Typically, assistance from a central processing unit (CPU) is necessary for maintaining a switch's forwarding database. For example, the CPU may remove or invalidate aged Layer 3 flows in the forwarding database. Also, the CPU may be used to update entries in the forwarding database or reorder the entries. If the CPU is to assist the search engine in maintaining the forwarding database, there must be a mechanism for the CPU to read, update, and otherwise manipulate entries in the forwarding database.
One approach is to provide the CPU with direct access to the forwarding database. Using this approach, the CPU updates the forwarding database using programmed input/output (PIO) instructions. Since, the direct access to the forwarding database will typically include glue logic of some sort, such as an arbiter or the like, with this approach both cost and complexity are increased. Further, the search engine may be forced to wait for an indeterminate amount of time for the CPU PIO accesses to complete before its accesses will be serviced. Therefore, the relatively slow speed of PIOs may cause inefficient utilization of the search engine's bandwidth.
This approach is further complicated in view of the fact that the memories typically employed for forwarding databases may provide tens or hundreds of low-level instructions for data manipulation. In this situation, a great deal of software must be developed for performing these low-level calls. While a forwarding database memory driver may be written to provide a layer of abstraction between the CPU 161 and these low-level calls, at some level the software must always know each and every raw instruction that is to be utilized.
Further, even with this layer of abstraction, the CPU will ultimately have to execute the raw instructions to gain access to the forwarding database. Since the relative amount of time required for forwarding database maintenance is dependent in part upon the number of instructions the CPU must execute during the maintenance, it should be apparent that this direct access approach is inefficient. Moreover, in the context of a distributed switching device in which multiple forwarding databases may be maintained, the above inefficiencies are multiplied by the number of distributed forwarding databases.
Based on the foregoing, it is desirable to centralize the forwarding database access mechanism. More specifically, it is desirable to provide the switch's CPU with hardware-assisted efficient access to the forwarding database to more efficiently utilize the switch fabric bandwidth and reduce the amount of time required for forwarding database maintenance. It would also be advantageous to make use of the switch fabric's knowledge of the low-level instructions for accessing the forwarding database to avoid duplicating interface logic to the forwarding database. Further, it is desirable to provide a relatively small set of independent forwarding database commands to assure bounded service time and reduced overall PIOs.